Subject: TCP single-pipe bringup

From: Scott Bales <[email-masked]>
Date: Tue, 24 Sep 1996 15:20:09 -0400

-->  Forwarded message:
-->  >From [email-masked] Mon Sep 23 08:46:17 1996
-->  Date: Mon, 23 Sep 1996 08:46:13 -0400
-->  Message-Id: <[email-masked]>
-->  Errors-To: [email-masked]
-->  Reply-To: [email-masked]
-->  Originator: [email-masked]
-->  Sender: [email-masked]
-->  Precedence: bulk
-->  From: [email-masked]
-->  To: [email-masked]
-->  Subject: Note from you attached below
-->  X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
-->  X-Comment:  DLSw scalability issues
-->  
-->  Dave, Thanks for the replies and all your efforts.  Comments below.
-->  
-->  Jon Houghton (IBM Corporation)
-->  
-->  >> ------------------------------- Referenced Note ---------------------------
-->  >> Received: from www.raleigh.ibm.com by vnet.IBM.COM (IBM VM SMTP V2R3) with TCP;
-->  >>    Thu, 19 Sep 96 20:56:51 EDT
-->  >> Received: from localhost.raleigh.ibm.com by www.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03)
-->  >>           id AA15759; Thu, 19 Sep 1996 20:56:31 -0400
-->  >> Date: Thu, 19 Sep 1996 20:56:31 -0400
-->  >> Message-Id: <[email-masked]>
-->  >> Errors-To: [email-masked]
-->  >> Reply-To: [email-masked]
-->  >> Originator: [email-masked]
-->  >> Sender: [email-masked]
-->  >> Precedence: bulk
-->  >> From: David.Bryant/HQ/[email-masked]
-->  >> To: [email-masked]
-->  >> Subject: Electronic AP for DLSw Multicast
-->  >> X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
-->  >> X-Comment:  DLSw scalability issues
-->  >>
-->  >> Sorry for the delay in responding guys... some long needed
-->  >> vacation and work crisises kept me away.
-->  >>
-->  >> Sounds like I'm going to have to put out a new version of
-->  >> the document to address some of the (very valid)concerns brought
-->  >> up.  So please get me your comments on these proposed changes
-->  >> by 9/25 and I will get a new verision of the spec out by 9/27
-->  >> and will want go AP on it if there are no substantial objections
-->  >> by 10/11.
-->  >>
-->  >> Here's a list of the issues (as I read them) and responses:
-->  >>
-->  >> [snip]
-->  >>
-->  >> 2). Single Tunnel activation with DLSw Multicast
-->  >>
-->  >> You guys are right.  I went into the document and changed the
-->  >> read port to 2067, but didn't look closely enough at what I was
-->  >> doing to realize I need to add clarification text.   It is my
-->  >> intent to say that DLSw Multicast nodes should establish a single
-->  >> TCP connection on 2067.   This still leaves a potential race
-->  >> condition whereby two DLSws bring up connections to 2067 at the
-->  >> same time.   In this case, the DLSw with the higher IP address
-->  >> must tear down it's connection after the capabilities exchange
-->  >> using a new reason code: x'000E' - unnecessary excess connection
-->  >> terminated
-->  >>
-->  >> This shouldn't create a problem when connecting to down-level
-->  >> (non-multicast) DLSw's because these types of connections must
-->  >> be predefined anyway.  So the DLSw should know to use the RFC
-->  >> 1795 method.
-->  >>
-->  >> Clarifying this will take some text in several places in the
-->  >> document... so it sounds like I'm sending out a new updated
-->  >> version.  Please give me your comments by 9/25, before I bother
-->  >> to do so.
-->  
-->  In the minutes of AIW 11, it is stated that a separate proposal on
-->  the bringing up of a single TCP pipe is to be available within
-->  2 weeks of the AIW.  "If the proposal was too late ...., it was
-->  not felt worth delaying v1.1 over this issue."
-->  
-->  Are you now accepting responsibility for this proposal and trying
-->  to merge it into the scalability document?
-->  We feel that this should be feasible, but are worried that it could
-->  drag out approval of this document - it is likely to take a few
-->  rounds of reviews and comments to nail down.
-->  
-->  If the group does choose to go this route, we would like to make
-->  sure the following questions and issues are addressed:
-->  
-->  1) If the read port is 2067, what is the write port?  Our assumption
-->  is that the write port is also 2067.  This makes TCP responsible for
-->  handling race conditions - DLSw should not have to do anything.
-->  If the write port is 2065, there could be race conditions that should
-->  be handled by DLSw and their handling needs to be documented.
-->  
-->  2) As you've already mentioned, it needs to be stated explicitly when
-->  read port 2067 is used.  We are assuming it is as you stated:
-->  If the partner is known to be multicast capable, send to read port 2067,
-->  otherwise send to read port 2065.
-->  
-->  3) It should be stated what is required support and what is optional
-->  support.  Obviously (we think), it is required to support listening on
-->  read port 2067.  But is it required to send to read port 2067?
-->  Or could an implementation continue sending to read port 2065 and bring
-->  up the connection the current way to a multicast capable partner.
-->  Saying it is optional gives implementations more flexibility, but
-->  opens up some race conditions.
-->  
-->  One note : it is likely that even if the document states that it is
-->  required to send to read port 2067 for all multicast capable partners,
-->  implementations which support both types of partners will still
-->  have to handle the possibility of receiving on read port 2065
-->  from multicast capable partners (customer configures multicast capable
-->  partners as partners, incomplete information about partner, ...).
-->  
-->  4) Do we need to document the race condition alluded to above.
-->  One partner is bringing up a connection from 2067 (or 2065) --> 2067.
-->  The other partner is bringing up a connection (perhaps a configuration error)
-->  from 2067 --> 2065.  If this race condition is to be handled, we should
-->  document which session is dropped and by whom.
-->  
-->  Note - I would not recommend using Neg Capex in these cases.  The
-->  TCP connection race conditions should be resolved prior to Capex.
-->  The Neg Capex should only be used to indicate a problem in the partner's
-->  Capex Req.
-->  
-->  5) Even though receiving a connection to read port 2067 implies that
-->  the partner is multicast capable and one TCP session is being used,
-->  it is assumed that these CVs in the Capex should still be present.
-->  
-->  We all agreed at the last AIW that things could only be improved
-->  by bringing up only 1 TCP session instead of bringing up 2 and dropping 1.
-->  But as we near CP on this document, our eagerness to hurry this function into
-->  this release of AIW function goes down - at some point, it is too late.
-->  
-->  I think we need some idea from others on whether there is still interest
-->  in adding this function.  Please append your thoughts so that Dave
-->  knows to continue.  From our point of view, if the above points are
-->  addressed appropriately in the document, we are willing to push it in.
-->  [snip]
-->  >>

I had taken the AI to look into "early rejection" of the TCP session in the
single-pipe bringup case.  I had written up a preliminary proposal, and
circulated to a subset of reviewers for comments - the comments I got back
lead me to believe that I would not be able to put together an acceptable
mechanism for this in time to get V1.1 to AP in an acceptable time frame.  
As such, I suggest that we move forward without "early rejection".

However, I still believe that we are close enough to a single-pipe bringup
solution for inclusion in V1.1.  As to the individual points above:

1) I would have imagined that the initiating station would be sending to TCP
port 2067, but I did not hear discussion of a limitation on what port it would
use as a source port.  I would advise that we not require the source port to
be 2067, and include about resolving the race condition.

2, 3) Since we have a CV specifying Multicast support, I do not think it should
be a requirement that a multicast-capable DLSw device use the single-pipe
bringup method (although certainly desirable) for peer connections it initiates.
It must, however, listen on 2067 and accept connections on that port as
specified.  Leave it up to the device when to use 2067 and when to use RFC 1795.

  It probably does make sense to say that single-pipe bringup must be used when
connecting a peer-on-demand as learned through Multicast - comments?

4)  I don't think the race condition of 2065 vs. 2067 is any bigger a problem
than currently existing race conditions; we just need to specify how to handle
it.  Since the connection on port 2067 has been accepted in this case, it is
clear both peers support the single-peer bringup - therefore, I would suggest 
that the peer initiating the connection on port 2065 bring down those pipes
and allow the port 2067 connection to stand (regardless of IP addresses).  Comments?

5)  Yes, the CV should still be present.  We don't want to tie multicast to
single-pipe bringup; we may come up with another type of peer that is multicast-
incompatible, but we still want to have the single-pipe capability.  The two
new features (Multicast and single-pipe) are not reliant on each other from a 
functional standpoint; it would be counter-productive to irrevokably link them
from the standpoint of the spec.

 - Scott

----- End Included Message -----